Title	GCC's -fstack-protector fails to guard dynamically-sized local variables on AArch64
CVE	CVE-2023-4039
Disclosure date	12th September, 2023
Affects	All versions of GCC that target AArch64 when option -fstack-protector is used.
Impact	Buffer overflows in dynamically-sized local variables might not trigger the stack-protector feature, and could allow an attacker to change program flow control in your application.
Resolution	Stack-protection can be enhanced by recompiling affected code using an updated GCC toolchain.
CVSS 3.1 Base Score	4.8
CVSS 3.1 Vector string	AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
Credit	Tom Hebb from Meta Red Team X and Maria Markstedter from Azeria Labs

What is the issue?

GCC's stack protection feature (enabled with the flag -fstack-protector) aims to detect buffer overflows in C/C++ function local variables that might allow an attacker to overwrite saved registers on the stack. If an attacker can modify saved register values then it might be possible for them to subvert program flow control. The feature operates by placing a canary value between local variables and saved registers on the stack on function entry, and triggers an error handler on function exit if the canary value has been unexpectedly modified.

When targeting AArch64, this feature did not protect the saved registers from overflows in C99-style dynamically-sized local variables and alloca() objects. Other local variables, including statically-sized local arrays, are not affected because of their different placement on the stack relative to saved registers. Further technical details of this issue can be found at Meta Red Team GitHub.

Arm has also examined GCC targeting AArch32 and clang targeting AArch32 and AArch64 and believes none of these are affected by this issue.

What is affected?

The specific conditions where the stack-protector fails to give the desired level of protection are when:

using GCC (all unpatched versions) targeting AArch64
and when the -fstack-protector option is used
and when the program uses C99-style dynamically-sized local variables or alloca()

And to be exploitable there must also be a prior vulnerability in the program such that an attacker can cause a buffer overflow in these local variables that overwrites saved register values in the stack.

What is the impact?

To exploit this stack-protector weakness it is necessary that another buffer overflow vulnerability exists. Assuming the stack-protector was providing the expected level of protection then any such buffer overflow would trigger the stack-protection feature and as per the default implementation would cause a controlled termination of the application (potential loss of availability). In the case that the stack-protector fails to spot the buffer overflow then the potential impact is uncontrolled loss of availability, and additionally might lead to loss of confidentiality or integrity depending on what an attacker can achieve by manipulating flow control. The incremental impact of this vulnerability relative to the stack-protector working is therefore on confidentiality and integrity, with availability unchanged (it is already impacted from the buffer overflow).

What is the fix?

Stack-protection can be enhanced by recompiling affected code using a fixed GCC toolchain.

Arm has published patches to the open-source GCC project to fix this issue. These patches cause GCC to generate an alternative stack frame that places all local variables below saved registers, with the stack-protector canary between them. Developers should be aware that the fixed compiler will generate slightly different code than before and this may impact code size or performance. The modified stack layout is local to each function and is not expected to introduce any binary compatibility issues.

The patches are:

Arm will incorporate these patches into future binary releases of the Arm GNU Toolchain. Users of other GCC-based toolchains should contact their software vendor for updates.

External resources

This information is provided subject to the Arm Security Legal Notices and Disclaimer.

Report Security Vulnerabilities

Reporting and Validation Process